This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

This PR was auto-closed because it has been stalled for 10 days with no activity. Please feel free to reopen if it is still valid. Thanks.

@zhouyuan @philo-he has a fix of #8293

FYI. From what I recall based on my previous investigation, the preferred approach is to dynamically link OpenSSL installed in user's environment to use the FIPS feature, rather than going through vcpkg.

FYI. From what I recall based on my previous investigation, the preferred approach is to dynamically link OpenSSL installed in user's environment to use the FIPS feature, rather than going through vcpkg.

I see. Since we didn't specify an absolute path for link, the difference here is only the openssl version liked to Gluten. FIPS is transparent at link time.

with this feature the libvelox.so will link dynamically

ldd cpp/build/releases/libvelox.so
        linux-vdso.so.1 (0x00007ffd4d590000)
        libgluten.so => not found
        libssl.so.3 => /lib64/libssl.so.3 (0x00007ff0e4c7e000)
        libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007ff0dbe00000)
        libm.so.6 => /lib64/libm.so.6 (0x00007ff0dbd23000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ff0dba00000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff0e4d81000)
        libz.so.1 => /lib64/libz.so.1 (0x00007ff0e4c62000)

@zhouyuan, thanks for the update. Not sure if my understanding is correct — I'd appreciate any clarification.

I've been trying to understand the practical usage of FIPS-enabled OpenSSL. It seems that in a production environment, the application should link against the OS-provided, FIPS-enabled and certified OpenSSL shared library. If so, are we enabling FIPS in vcpkg primarily for development verification? The certification process is complex and isn't designed to be repeated for every build.

From what I've gathered:
Build time (vcpkg): Use FIPS-enabled OpenSSL for development/testing to ensure the code is FIPS-compatible.
Production: Link against the OS's certified OpenSSL, not the one built from source.

Does this align with the intended approach?

with this feature the libvelox.so will link dynamically

ldd cpp/build/releases/libvelox.so
        linux-vdso.so.1 (0x00007ffd4d590000)
        libgluten.so => not found
        libssl.so.3 => /lib64/libssl.so.3 (0x00007ff0e4c7e000)
        libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007ff0dbe00000)
        libm.so.6 => /lib64/libm.so.6 (0x00007ff0dbd23000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ff0dba00000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff0e4d81000)
        libz.so.1 => /lib64/libz.so.1 (0x00007ff0e4c62000)

Just to confirm – When using vcpkg to build shared OpenSSL libs, aren't those libs installed under the vcpkg installation directory?

@philo-he In Gluten we only need to enable dynamic linking with openssl when packaging with vcpkg, which is not available in current impl. This patch enabled this feature. Note this is not enabled by default, so all community release won't be impacted

FIPS-enabled OpenSSL

The vender need to provide a fips.so in local runtime, the OS will need to make sure all libs are available on LD_LIBRARY_PATH

When using vcpkg to build shared OpenSSL libs, aren't those libs installed under the vcpkg installation directory?

Right the example here is to demonstrate the different linking at runtime

LGTM. Thanks. cc @FelixYBW

Not sure if users will prefer linking against OS-installed, certified OpenSSL libs at build time. If so, we could allow bypassing the vcpkg OpenSSL build and let CMake find the system libs instead. Since this isn't determined yet, we can do the follow-up if needed in the future.

Could you document this clearly in a separate PR for users to reference? Perhaps, we can include the following clarifications. Thank you.

1. At runtime, LD_LIBRARY_PATH should point to the OS-provided OpenSSL package, which includes libssl.so, libcrypto.so, and the FIPS-certified fips.so.
2. Users should ensure compatibility between the OpenSSL libraries (libssl.so and libcrypto.so) used at link time and those available at runtime. We recommend using the same OpenSSL version for both to avoid potential issues.

@philo-he, you are right. Ideally, we should link to libssl in the target system. We have below choices:

1. link the version in vcpkg, load the same system version on target machine. -- no issue
2. link the version in vcpkg, load different system versions on target machine. -- potential issue
3. link the version in vcpkg, release the libssl.so in vcpkg with Gluten jar together, set LD_LIBRARY_PATH to the released one -- no issue.
4. link the version in dev system, load the same version on target machine. -- no issue.
5. link the version in dev system, load different version on target machine. -- potential issue

If 2 or 5 happens, developer either need to update the version in vcpkg/dev system or the one on target system.

We just think openssl is stable enough, linking with vcpkg is much easier than system one. Let's try this solution first, and switch to yours once we encounter issues.

@zhouyuan can you add the config to https://github.com/apache/gluten/blob/main/docs/get-started/build-guide.md? Also list the openssl version in vcpkg?